home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 18197 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  1.2 KB
  1. Path: ix.netcom.com!news
  2. From: giuliano@ix.netcom.com(Giuliano Carlini)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Slow longjmp in Watcom 10.0
  5. Date: 18 Apr 1996 20:31:29 GMT
  6. Organization: Netcom
  7. Message-ID: <4l68r1$7jc@dfw-ixnews6.ix.netcom.com>
  8. References: <4kvejg$ne9@goanna.cs.rmit.edu.au>
  9. NNTP-Posting-Host: lbx-ca5-09.ix.netcom.com
  10. X-NETCOM-Date: Thu Apr 18  3:31:29 PM CDT 1996
  11.  
  12. In <4kvejg$ne9@goanna.cs.rmit.edu.au> jtai@numbat.cs.rmit.EDU.AU (Jason
  13. Chen Hiung Tai) writes: 
  14. >
  15. >I did a test of longjmp under OS/2 using Watcom C/C++ 10.0 on
  16. >a P90. What shock me was that it took almost 2400 cycles or ...
  17.  
  18. It's been a while since I messed with longjmp with Watcom, so take this
  19. with a boulder of salt...
  20.  
  21. If I remember correctly, Watcom's longjmp is unwinding some runtime
  22. data structures. These data structures are normally used to call the
  23. destructors for C++ objects on the stack. longjmp has to unwind these,
  24. or the runtime gets really confused, and has a stroke. Borland has a
  25. flag to disable exception handling. Does Watcom have a similar flag. If
  26. so, it may make longjmp more efficient. The only way to tell for sure
  27. is to single step the longjmp code in the debugger. Painful, but
  28. necessary.
  29.  
  30. g
  31.